- Published on
- ·
JIRA로 스크럼 시작하기
Jira Software
Atlassian에서 개발한 Jira는 스크럼의 철학을 완전히 탑재한 프로젝트 관리 도구입니다. 백로그, 칸반, 스프린트, 번다운 차트 등 스크럼을 하기 위한 도구들이 포함되어 있고, 자유도가 높습니다. 팀에 맞게 잘 커스텀한다면 꽤 괜찮은 스크럼 프로세스가 세팅됩니다.
저희팀이 JIRA를 어떻게 활용해서 스크럼을 진행했는지 살펴봅시다.
팀 구성
프론트엔드 개발자 2명, 백엔드 개발자 1명, 디자이너 1명으로 총 4명입니다. 스크럼에 대한 이해도가 제일 높은 다른 프론트엔드 개발자 한 분이 스크럼 마스터를 맡았습니다. 저는 해당 프로젝트 기획에 가장 깊게 이해하고, 관여하여 프로덕트 오너를 맡아 백로그를 작성했습니다.
일일 스크럼
평일 오전 11시에 구글 미팅을 통해서 15분 동안 스크럼을 진행합니다. 각 인원이 빠르게 3가지를 공유하고 끝냅니다.
- 지난 스크럼부터 이번 스크럼까지 한 일
- 이번 스크럼부터 다음 스크럼까지 할 일
- 방해 요소
Notion 활용
Confluence 대신 데일리 스크럼을 기록하기 위해 노션에 템플릿을 만들어 활용하고 있습니다. 각자 스크럼 전에 회의록에 이슈 넘버를 기반하여 작성하고, 미팅 시간에 구두로 공유합니다. (아래 처럼 Notion에서 JIRA티켓을 임베드 할 수 있습니다) 
벌금
일일 스크럼 미팅이 원할하게 진행되기 위해서 벌금을 정했습니다. 지각 5,000원 결석 10,000원입니다. 스크럼 시간이 15분 밖에 되지 않기 때문에 지각이 결석으로 이어질 확률이 높습니다. 스크럼 시작 시간은 1분도 지체되지 않고 시작되기 때문에 모든 인원이 정해진 시간에 항상 다 모이기 위한 장치를 마련했던 것이고 실제로 벌금 시스템 덕분에 일일 스크럼 미팅이 더 잘 진행되고 있습니다.
스프린트
첫 스크럼이고, 첫 스프린트이며, 프로젝트의 기간도 길지 않기 때문에(11월 말 까지) 스프린트 주기가 1달이면 리스크가 너무 크다고 판단했습니다. 팀이 스크럼에 익숙치 않으니 빠르게 시행착오를 겪고, 검토하고, 피드백 받는 주기로 1주일이 적당하다고 판단했습니다.
1주 → 2주
2번의 스프린트를 끝낸 후, 1주 단위는 한번의 스프린트 내에 해결할 수 있는 스토리가 너무 제한적이며, 플래닝과 리뷰에 들어가는 오버헤드가 크다고 판단했습니다. 결국 2주로 조정했습니다.
스프린트 계획 회의
스프린트 계획 회의는 2단계로 진행했습니다.
- 스프린트 목표를 정하고 각 팀원의 가용 시간 및 총 가용 시간을 추정합니다. 그리고 스프린트 기간 동안 예상되는 방해요소를 팀원들끼리 공유합니다.
- 스프린트 목표에 맞는 스프린트 백로그를 작성합니다.
스프린트 검토 회의
스프린트 마지막날 담당 멘토님과 스프린트 결과를 공유하고, 팀원들 끼리 3Ls(Liked, Lacked, Learned)로 지난 스프린트를 리뷰합니다. 아래는 첫번 째 스프린트 검토 회의에서 얘기한 내용입니다. 
스프린트 검토 회의도 몇번의 시행착오를 겪으며 계속 발전시켰습니다. → 우리팀의 스프린트 회고
티켓 범위 설정하기
우선 티켓은 Jira와 같은 프로젝트 관리 소프트웨어에서 사용되는 용어로, 어떤 작업이나 이슈를 말합니다. 백로그에 들어가는 각각이 티켓입니다.
스토리, 에픽
스토리는 사용자의 관점에서 기능이나 요구사항을 설명하는 용어이며 Jira에서는 티켓의 한 종류로 취급됩니다. 저희는 기능 명세서에 상세 기능 단위로 스토리를 백로그에 추가했습니다.
에픽은 관련된 스토리들을 그룹화 한 상위 구분입니다. 각각 스토리나 태스크들에는 에픽을 연결할 수 있습니다. 초록색 아이콘과 제목이 스토리, 옆에 보라색 글씨가 에픽입니다. 
태스크
스프린트 계획회의를 할 때 정해진 이번 스프린트 동안 어떤 스토리를 해결할지 정하고, 스토리를 완수하기 위해 해야하는 태스크들을 추가했습니다. 
하위 태스크
어떤 태스크는 추정 시간이 길고, 그 안에서 하위 태스크를 만들어야 할때도 있습니다. 다만 하위 태스크 단위보다 더 잘개 쪼개진 않았습니다. 
워크플로 설정
모든 티켓들은 워크플로우 프로세스를 통해 관리됩니다. 
작업이 완료되면 바로 Done으로 가는 것이 아니라, In Review 단계에서 Reviewer에게 검토를 받습니다. 검토 대상은 코드가 될 수도 있고(Pull Request), 디자인, 기획이 될 수도 있습니다. 물론 리뷰를 받을 필요가 없는 것들은 개인의 판단하에 Done으로 바로 보낼 수 있습니다. 다만 번다운 차트가 정확하게 그려지려면 In Review 상태에 있는 다른 팀원들의 작업을 빠르게 리뷰해줄 필요가 있고, 리뷰를 받을 필요가 없는 것들은 바로 Done으로 보내야 합니다.